home *** CD-ROM | disk | FTP | other *** search
- Path: interramp.com!usenet
- From: us011245@interramp.com
- Newsgroups: comp.lang.c++
- Subject: Re: when to inherit, when to compose...
- Date: Tue, 26 Mar 96 18:20:56 PDT
- Organization: PSI Public Usenet Link
- Message-ID: <NEWTNews.17513.827895367.hampton@interramp.com>
- References: <31587163.1045@datalytics.com>
- NNTP-Posting-Host: ip216.herndon7.va.interramp.com
- Mime-Version: 1.0
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage
-
-
- In article <31587163.1045@datalytics.com>, <stew@datalytics.com> writes:
- >
- > John Peter Lee wrote:
- > >
- > > Hi:
- > >
- > > I'm wondering about an OO design. Under what circumstances is it more
- > > advantageous to use an inheritance hierarchy for a design, as opposed
- > > to using object containment, and vice versa?
- > >
- > > With object containment: class "A" has a member class "B" declared
- > > within it. A acts as a kindof handle class (I think) that forwards
- > > requests to B, and handles B's output.
- > >
- > > With inheritance: class "A" is a base class, and class "B" is a derived
- > > class. Then A has virtual functions that are implemented in B.
- > >
- > > -> Are there any general rules of thumb to apply here? Any literature?
- > >
- >
- > The obvious one is correct, but not always easy to recognize:
- > inheritance applies only when the derived class is a form of the
- > base class, you inherit. When it just happens to need to do
- > things another class offers, you use the other class. Those are
- > easy statements to make. They aren't so easy to practice.
- >
- > It really comes down to deciding if everything about the other
- > class is just like your new class except your new class adds a
- > few twists of its own. This is when you use inheritance. If
- > the other class has things that aren't really right for your new
- > class, then you probably need to use the other class. However,
- > you might also want to consider creating a common base class so
- > that your new class and that other class derive from it.
- >
- What you're talking about is sometimes called delegation. It works like
- this: if I want to implement a stack class, and easy way to do it is to use
- some existing class. Suppose that I have a list class already. I can
- implement the stack by using the list class operations. In particular, I can
- implement push by adding an element to the top of the list and pop by removing
- the element at the top of the list.
-
- OK that's cool. The question is, should my stack class inherit from List as a
- parent class, or should I just hide a list in my stack object and write push
- and pop operations which manipulate this list out of sight of the user. That's
- the rub. As you can see, if I use inheritance to implement the stack class
- from the list class, the user will have access to all the public operations of
- a list, such as sticking things on the end of the list or even (gasp!) in the
- middle of the list. Great behavior for a list but uncool behavior for a stack.
- If I use delegation instead, that is, I hide a list in my stack class and
- provide only push and pop operations to the public, then objects using my stack
- class will have no access to the underlying list operations, they won't even
- know that a list is there. The decision therefore as to whether to use
- inheritance or delegation will often revolve around whether the user requires
- access to the underlying implementation and whether that access is consistent
- with the class you're trying to implement. I.e., if it makes sense for a user
- of class X to use class Y's public operations, then inherit from class Y,
- otherwise, hide an object of class Y in class X and use private operations on
- the hidden class to implement class X's operations.
-
- Regards,
- Luther Hampton
-
-
-